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(54) IP multicast over a wireless ATIW network 

(57) The present invention provides IP multicast 
using over wireless ATM. A wireless ATM system con- 
sists of a fixed core network and a shared wireless 
access link for mobile terminals. Unlike point-to-point 
ATM links within the fixed/wired network, wireless ATM 
link uses a common VC space for all mobile terminals 
and the medium access (MAC) protocol allows multiple 
access on the downlink, but supports only unicast trans- 
mission on the uplink. This invention also provides how 
IP multicast can be naively supported on such WATM 
links through specific extensions to the Internet Group 
Management Protocol (IGMP). In addition, a cell-level 
error recovery scheme at the DLC (data link, control) 
layer is provided to enhance the (IP) packet-level output 
of the transport layer. 
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Description 
I. DESCRIPTION OF THE INVENTION 

[0001 J This application claims priority from co-pending s 
U.S. Provisional Patent Application Serial No 
60/081,628 filed on April 14. 1998. 

lA. RELD OF THE INVENTION 

10 

[0002] This invention relates to wireless Asyncronous 
Transfer Mode (ATM) networks. Specifically, it deals with 
computer communications and networking; and in par- 
ticular to a method of transmitting - on a wireless ATM 
network - a packet formed in accordance with a protocol is 
different from ATM and to a network system for transmit- 
ting the packet. 
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[0003] Wireless ATM has been an active area of 
research and development. ATM Forum and ETSI, 
applicable bodies, are standardlng wireless ATM. Such 
a wireless ATM is useful for providing broadband wire- 
less sen/ices. A conventional wireless ATM system, e.g. 25 
WATMnet comprises two major components: (a) a fixed 
core network and (b) shared wireless access link used 
for extending ATM cell transmission to mobile hosts. 
See D. Raychaudhuri. L. J. French. R. J. Siracusa. S. K. 
Biswas. R. Yuan. P. Narasimhan. and C. A. Johnston. 30 
"WATMnet: A prototype wireless ATM system for multi- 
media personal communication", IEEE Journ. Select 
Areas Commun, , Jan. 1 997. 

[0004] Other conventional wireless ATM systems have 
been described in D. Raychaudhuri. L. J. French, R. J. 35 
Siracusa. S. K. Biswas. R. Yuan. R Narasimhan. and G. 
A. Johnston, "WATMnet: A prototype wireless ATM sys- 
tem for multimedia personal communication". fEEE 
Journ. Select. Areas Commun,, Jan. 1997. 
[0005] Techniques for providing mobility support 40 
through conventional mobile ATM have been described 
in A. Acharya. J. Li. B. Rajagopalan. and D. Raychaud- 
huri, "Mobility management in wireless ATM networks". 
IEEE Commun. Mag., 1997. Providing Internet Protocol 
(IP) support within a core network is described in Arup 45 
Acharya. Rajiv Dighe. and Furquan Ansari. "IP switch- 
ing over fast ATM cell transport (IPSGFACTG): Switch- 
ing multicast flows". Proc. IEEE Globecom, 1997 and 
Arup Acharya. Rajiv Dighe. and Furquan Ansari. "A 
framework for IP switching over fast ATM cell transport so 
(IPSGFACTG)". Proc. SPIE, 1997. 
[0006] A method for IP switching over ATM and an 
embodiment of IPSGFACTG Is described in detail in 
copending U.S.Patent Application No 08/771.559 by 
Acharya et al. and U. S. Patent Application No ss 
09/080.208 by Acharya et al.. which are incorporated 
herein by reference. 
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[0007] IPSOFACTO (IP Switching Over Fast ATM Ge!l 
embodiment of a methodology for map- 
pmg IP flows to a switched path (virtual connection) 
within a network of ATM switches. Unlike standard IP- 
over-ATM techniques described generally in James V. 
Luciani, Dave Katz. David Piscitello. and Bruce Cole" 
"NBMA next hop resolution protocol (NHRP)", Internet 
Draft, idraft'ietf'rolc-nhrp'is.txtj, Work In Progress- 
Mark Uubach. "Classical IP and ARP over ATM". ATM 
Forum and Andre N. Fredette (Editor). "Multiprotocol 
over ATM version 1.0 (baseline text version 16)". ATM 
Forum.; the ATM signalling stack is not used to setup a 
connection between endpoints. 

[0008] First datagram of a new IP flow sets up the con- 
nection between endpoints hop-by-hop as it traverses 
through the ATM switches. See Arup Acharya. Rajiv 
Dighe. and Furquan Ansari. "IPSG-FACTG: IP switching 
over fast ATM cell transport". Internet Draft, jdraft-acti- 
arya-ipsw-fast'Cell^OO.txtj, 1997; Arup Acharya. Rajiv 
Dighe. and Furquan Ansari. "A framework for IP switch- 
ing over fast ATM cell transport (IPSGFACTG)". Proc. 
SPIE, 1997; and Arup Acharya. Rajiv Dighe. and Fur- 
quan Ansari. "IP switching over fast ATM cell transport 
(IPSGFACTG): Switching multicast flows". Proc IEEE 
Globecom, (1997). 

IB.l(a) Basic Operation of IPSOFACTO 



[0009] The basic premise of operation for the conven- 
tional methodology followed in IPSGFACTG is that all 
IPSGFACTG VCs in an input port have a mapping, 
either to the switch control processor or to an output 
port. It should be noted that a switch may be configured 
to have VCs for IPSGFACTG. ATM signalling etc Un- 
configured IPSGFACTG VCs - which can cause data to 
end in a black-hole are not present. All unused VCs on 
the input port of a switch are mapped to the switch con- 
trol processor. Data transmitted on an unused VC 
always reaches the controller, which runs the complete 
conventional IP protocol stack, including the necessary 
IP routing protocols. 

[001 0] Fig. 1 shows an example of the basic operation 
of the above-mentioned IPSGFACTG. Each port of the 
switch is configured to be an IP interface. The IP routing 
table shown in the figure consists of routes to destina- 
tion networks. 1.2 and 4.1.2. with outgoing interfaces 
set to interfaces 2 and 3 respectively VC 82 on in-port I 
is initially mapped to the control processor. 
[001 1 ] A cell-level switched path for data forwarding in 
the above system is established in the following way A 
sender selects an unused VC on an outgoing link to for- 
ward the first packet of a new flow. This is received by 
the switch processor at the downstream end of the link, 
which then selects outgoing link(s) based on its IP rout- 
ing tables. This first packet is then forwarded by the 
processor on the selected outgoing links by picking an 
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unused VC on each link. 

[001 2] In FIG. 1 . an upstream router selected VC 82 to 
switch a new flow: the first packet of this flow is received 
by the router shown, which then inspects its IP routing 
tablets to select an outgoing interface (3 in the present s 
case). On interface 3, VC 51 is selected for forwarding 
the packet to the downstream router. Since the switch 
control processor has the complete information (input 
port, input VC. output port, output VC > necessary to 
switch the flow, it adds an entry into the switch VC io 
tables. Ail succeeding cells are switched; eliminating the 
need for subsequent packet level forwarding at the con- 
trol processor. 

[001 3] In contrast to data packets, which are switched 
at cell level, a switched path is never created for IP con- is 
trol messages. Typically, the control messages are sent 
and received on a predefined control VC. Therefore, 
such control messages are forwarded through all switch 
control processors. This mechanism is used to establish 
a per-f low forwarding state. Changes in the fonwarding 20 
state, e.g. pruning an outgoing interface, are then used 
to modify the switched path (e.g., deleting an < out-port, 
VC) from the VC tables). When the forwarding state is 
removed from the control processor, the corresponding 
switched path is released, by marking the input and out- 25 
put VCs as unused. 

1C. WIRELESS ATM SYSTEM 

[001 4] A setup of a conventional wireless ATM system 30 
is shown in FIG.2. In such a network architecture, the 
base-station provides connectivity to the mobile termi- 
nals via a wireless link e.g. a radio link. The base-station 
is also connected to the core network via wired links. 
Data from the wired interface to the wireless interface is 35 
cell-switched at the base-station and ATM cells (within a 
TDMA frame) and are carried over the radio link to the 
mobile terminals. This provides end-to-end ATM con- 
nectivity Each base-station can support a given number 
of mobiles within its domain. 40 
[0015] A dynamic TDMA/TDD (Fig. 3) protocol with 
centralized control is used for radio access on the 
WATM link. Downlink information from the base-station 
including control information and ATM cells, are multi- 
plexed into a single burst and transmitted at the start of 45 
the TDMA frame (following the preamble and frame 
header). The base-station controls the allocation of 
slots to mobiles in the uplink. Uplink control information, 
which includes requests for bandwidth allocation, is 
sent in a slotted ALOHA contention mode. Details of the so 
TDMA/TDD frame format are described in P. Narasim- 
han. S.K.Biswas, C.A.Johnston. R.J.Siracusa, and 
H.Kim, "Design and Performance of radio access proto- 
col in WATMnet, a prototype wireless ATM network", 
Proa ICUPC, 1997. 55 
[001 6] For IPSOFACTO. it is important to note that all 
cells on the downlink burst are received at the radio- 
layer at all mobile terminals. However, the MAC layer at 




each mobile terminal ii^&^^^^^^^^M 
VC numbers, and fbnaards onli?1R^^^^^^t^^ 
layer for which a VC has been pf^il^^^^^|<^ 
ternninaL The uplink transmission fe^pgii^^^^^i^' 
each slot carries a cell from a terminal to^fif bascf^- ' 
tion: the MAC layer at the base-station fonvards a cell to 
the DLC only If the associated VC is already open. The 
VC space in both directions is common to all mobile ter- 
minals. In case of a conventional wireless ATM system 
where the access link is shared among all mobiles, sep- 
arate control VC is used for each mobile. 

IC.1. Background 

[001 7] Transmission of IP packets to a subset of hosts 
on a network is called as multicasting. Some main ben- 
efits of multicasting include lower network and host 
overhead in sending a packet to a group of receivers. 
Class D addresses of the IP (IPV4) address space 
(224.0.0.0 to 239,255.255.255) are reserved for multi- 
cast operation. A multicast address does not identify a 
particular IP interface in the Internet but instead identi- 
fies a group of interfaces. Multicast is well supported by 
local area networks such as Ethernet that provide effi- 
cient broadcast delivery and a large multicast address 
space. 

[0018] Hardware-level filters in the network interface 
card filter out unwanted datagrams before they reach 
the IP layer. For the hardware filters to work, the net- 
work interface must convert the IP multicast group des- 
tination to a link-layer multicast address recognized by 
the network hardware. The Ethernet multicast address 
is created by mapping the lower 27 bits of the IP multi- 
cast address to the last 23 bits of the Ethernet address. 
See Gary R. Wright and W. Richard Stevens. "TCP/IP 
Illustrated, Volume 1: The protocols", Addisson-Wesley 
Publishing Co.. Reading. Massachusetts (1995). In 
addition, multicast routing protocols are required within 
the network to copy and forward a packet to multiple 
destinations within the network, 

IC.2. Multicast on point-to-point links 

[001 9] Multicasting on point-to-point links using IPSO- 
FACTO is also relatively straightfonward. The first IP 
packet of a multicast flow arriving at the switch controller 
will install a forwarding cache entry in the multicast for- 
warding cache. The VC number and the port number 
(selected by the upstream switch controller) on which 
the packet arrived it obtained. Further, for each outgoing 
interface in the newly created multicast forward cache, 
IPSOFACTO selects an unused VC to fonward the 
packet to the downstream switch controller. It then adds 
an entry to the switch hardware VC tables correspond- 
ing to input port, input VC -> list of output port, output 
VC. All subsequent packets in the flow are switched at 
the cell level making use of the hardware multicast 
capability of the ATM switching fabric. 
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[0020J Mufticasting on shared ««r«i« 
provide some new challengS ""'^^ 
«nk is broadcast in thTSr^n '"'^ ^ 

upHnk. Providing muKcl^T^ ''""'^^ »he 5 

requires ustouslamapSgof^^^^^^^^^^ 
to the link-iayer address'Ll o eLm^^^^^^^^ 
belonging to the multicfl<:t r.,! Mobiles not 

unwanted data approSLTr."^^ *° 

'ink-layer identi,.SSessi^^^^^^ "^'^^ 
(VC) number. A mappS^ S ^^^^^ 
a VC number is reauJed to T ^='^^ess to 

10021, AnotherSTet? A^rr 
the effective transport layer hrotof^ ^^'^'"'^*'^* 
""proved. Since the'bit errorrareTelR) *° - 

much higher than that of a f ix2l A^^ ? ""'^ 
level error recovery mechanismiL w"^*^"'*^' ^ 
degradation of the packet lllT, V^^'''^ '° P^^«"t a 
ievelrecoverymecha4ms;^^^^^^^^ '^^ 

for unicast connection TJS^ ^iTS^^^^^ - 
asimhan. R. Yuan and D r^^^ ^ "^ar- 

trol protocols for wirel^' ^;>J^^"dhuri, "Data linkcon- 

/C^^W, 1995. MapptnT/P mulSt"^,"'"""^'^" 
VCs (using UBR) reSSe™ w """"^ *° '"""'Cast 
recovery fand XenS ^^^^ ^^^^ - 

multiple recipients mechanism to handle 

SSgp^^m?"^' at ieast has the 

* t^Snrsrhre%tl^^^T''■"^ 

reafee the full po enS aJr ' t° 
gies like IPSOfSto technolo- 

* Xr^Xt™, -^^^^^ OOMP) is . 
agement protocol, version 2" 

Further extensions and aS^Sfi " 
SUMMARY OF THE INVENTION 

Ssting r"«°" ♦° p--^^ 

'ocol for transmit^^gTparetZ^H^^'^"''^"''^^ 
-ork to a destinatfon sa'd sSm ^™ 
^ce for transmitting a sequence of ATM T'*"^ ^ 
-used Virtual Channel WentifierTvS^'^^nH " "'"^ 
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When each of the ATlSra^a^vST,^^ ^l'' 
unused VCl. wherein r^.Tiiv . w. ^ '^'entical with the 
are obtaine<^ by r^Za S ^''^"^'^ <^Cs! 

'P multicast grL^JT VC Jumnr «'^^^^P°"di"g to 
said multicast VCs arJtlh. ^ corresponding to 
«on uses said ma^ trprjide'Vc? T 
mo^sioi^ngoneofLdHS^^^^^^^^ 

base^tatiordrd™^^^^^ wherein a 

and mobiles. StiS fu?mer^mnr°"''^"'=^ "^'^^^^ ^Cs 
tern Wherein a uZfr!^^?r"'T '""'"^^ ^V^- 
base-station to mobi lesln^L h^^^^^^ '^""^ 
between the base^t^L .1 ^Cs 
«>ntro, messages XTe::^:::^^'''' ^^"^'"^ 
Cnth?Sr:j,r^^^^^ —01 
REQUEST and a vd recl a^m''^" """^P^^^^ 
Wherein said VC REQUEST '"Usages, 
mobile to request Thl k '"^^sage is used by a 
data, and wSr^n i'^ S^rS^J" ' '° 
by the base-station to reSaVm^n w^'^^^^^S^ "^ed 
mobile. VC assigned to the 

wheri .h;rs:sS~ a 

-ityinaVCandrec,:rS;,r^^^^^^^^^^ 

t^b^e^tlrcrnT^^^^^^^ 
merge .ultipleflowsin^^^^^^^^ boundaries and 

the"L-:Strss~^ 

'P address, multicast SouoTh? ^^ ^^^^^r 
Preferably the basTstltrpSSlv' b 
mappings, wherein mobiles n^T^ ^ broadcasts the 
drop said message at IP ,11 *'T''^'"^'^«^«9« 
fnterestedinameLaoL^i^ ' ^"'^ "mobiles 
preferably said brSdcLrr "^''^P^^-"^ VCs. More 
Membership QuerT r^esSge '°'^P Host 

'St Grp°*'^a~^ ^ -'herein 
e^fended such'thaTquer es ?n ZT"" ^'^^^^ 
'GMP messages are °ransmitt^ ^"^ °' ^^^""n'^ 
Wherein multicast moVS S SiiT^^^^^^^ 
and generate appropriate r Jf^;. 5 messages 
t/cast mobiles d^^ S^S^MP ^;,^^ 
f003l J Yet annfh^cT messages at IP level 

'nternit SouTZToZlTV' ' ^^--n 
extended such mat repon^^^^^^ ^'^^^^ 's 

messages are transmSt^ ' , °' """"'^ '^^^ 
wherein the base-staZ^h I '^°"'^o' VC. 

sages so that Sii SlS 

sages.wherein mobiles Jher thr" '^"^ '^^^ "^^S" 
the IQMP message res2 11 ""^'^ 
reports being generltZl ^' Preventing more 

r0032J >^notheraspectofthisinventionisamu,«cast 
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/flow system for transporting multicast traffic across a 
radio layer, wherein a data link control protocol (DLC) 
uses a negative acknowledgment (NACK) scheme, 
where a receiver sends a NACK along with a bitmap 
vector only when said receiver has lost cells or said 5 
receiver has received corrupted cells. Further improve- 
ments includes the system wherein timers are used to 
prevent deadlock, wherein transmitted ceils are stored 
in buffers until said timers expire and said buffers are 
cleared after said timers expire. Preferably receivers w 
maintain receiver timers when a loss is detected, the 
receiver timers having a timeout value approximately 
the same as timeout values of the timers that are used 
to prevent deadlock. More preferably receivers request 
retransmission until expiry of said receiver timers. 75 
[0033] Improvements include the system wherein 
transmitters have gratuitous acknowledgment timers 
having timeout values approximately half the timeout 
values of the receiver timers, wherein the transmitters 
resets the gratuitous acknowledgment timers when 20 
there is more data to send, and wherein the transmitters 
send a gratuitous ACK message after the transmitter 
has transmitted last group of cells. Preferably when the 
receiver receives the gratuitous ACK message contain- 
ing sequence numbers of transmitted cells, the receiver 25 
determines if a cell loss occurred and send back a 
NACK message indicating that a cell loss has occurred. 
[0034] Another aspect of the present invention is a 
wireless ATM system wherein a VC space is divided into 
unicast VCs. broadcast VCs and multicast VCs. 30 
Improvements include the system wherein unicast IP 
addresses are mapped to said unicast VCs. 
[0035] Another improvement is a system wherein mul- 
ticast IP addresses are mapped to said multicast VCs. 
[0036] Yet another improvement is a system wherein 35 
broadcast IP addresses are mapped to said broadcast 
VCs. 

[0037] Another aspect of the present invention is a 
method of joining a multicast group for a mobile, said 
method comprising: initiating contact with the base-sta- 40 
tion over a wireless control channel; receiving a 
response at the mobile, wherein said response com- 
prises a broadcast VC number and a unicast control VC 
number that the mobile should use; sending an IGMP 
join message on the control VC; searching a base-sta- 45 
tion database to see if a mapping of (group, VC 
number) exists; picking a VC from available VC pool 
and creating for a said VC (multicast group. VC 
number) and storing information in the database if said 
mapping does not exist; providing the existing mapped so 
VC if said mapping exists; transmitting ( group address. 
VC number) to the mobile over broadcast VC; opening 
the VC corresponding to the mapping (multicast group. 
VC number) for data reception. 

[0038] Further improvements include the method fur- ss 
ther comprising: sending a host membership query on 
the broadcast VC (255); dropping this message if a 
mobile does not belong to a multicast group; starting a 
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report delay timer with a randomly chosen expire value 
if a mobile belongs to the corresponding nnulticast 
group; sending a host membership report on the broad- 
cast VC if said timer expires; rebroadcasting the host 
membership report; and resetting the timer and not gen- 
erating the report on receiving the rebroadcast. 
[0039] Another aspect of the present invention is a 
method of leaving a multicast group for a mobile, said 
method comprising: sending an IGMP leave message 
to base station using control VC, decrementing a coun- 
ter associated with a corresponding VC. checking to see 
if said counter has reached zero, continuing transmis- 
sion on the VC if counter has not reached zero, closing 
corresponding VC for the mobile and sending a prune 
message if all the counters go below zero. 
[0040] Yet another aspect of the present invention is a 
method of mapping mobiles with multicast groups for 
use in deleting said mobiles from said multicast groups 
said method comprises maintaining a database of ail 
mobiles associated with the multicast group and map- 
ping a multicast group with a subset of all mobiles join- 
ing the multicast group. 

[0041] Still another aspect of the present invention is 
a method of mapping mobiles with multicast groups for 
use in deleting said mobiles from said multicast groups 
said method comprise mapping a multicast group witii a 
counter, wherein the counter is incremented when a 
mobile joins the multicast group and decreased when 
the mobile leaves the multicast group. 
[0042] Still another aspect of the present invention is 
a method of mapping mobiles with multicast groups for 
use in deleting said mobiles from said multicast groups 
said method comprises implicitly assuming presence of 
mobiles from multicast outing protocol and sending 
prune message upstream when no mobiles are associ- 
ated with a multicast group. 

III. LIST OF FIGURES 

[0043] The above objectives and advantages of the 
present invention will become more apparent by 
describing in detail preferred embodiments thereof with 
reference to the attached drawings in which: 

Fig. 1 shows an example of a conventional IPSO- 
FACTO operation. 

Fig. 2 shows a conventional setup of a wireless 
ATM system. 

Fig. 3 shows the TDMA/TDD Frame format for use 
in wireless ATM. 

Fig. 4 shows a logical representation of the Data 
Link Control Protocol for Multicast Traffic. 
Fig. 5 shows a selective retransmission mecha- 
nism. 

Fig. 6 shows timing information for the NACK based 
mechanism 
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to the mobiles 
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irintru^sfi^cs^^^^^^^^^ . 

VCs for supporting diffe eX?s LlS^^^^ 
the present invention. Data trS,smS2 ' ^^'^''''^S *° 
.3 received by only one r^c^S^lZ^sT^^Tr' 
*ed by a broadcast VC is recp/v^w k f *^ transmit- 
the other hand, data t anS£ J! ^" 
je^KjedbyonlyasubSt-ro^le^ ^ 

address. VC> the ba«!olto4- ' multicast group 

With the VC nu^ituTZnT'^- '"^"^^ 
multi-cast group, a one to o^- - ^^""^ 
between VCs andVp muttLT ^"'"^ maintained 
f0048J Theasvmr^* *^'°"P^^^^esses. 

access «nk reou'^es "S "^^^^ °' "'^^'^^ ATM 
protocol for prX 4n^r °"'*° IPSOFACTO 
VC space 'slsZb^s ZI^^^ ^'"'^ 
fon. VCs cannot brirLT^fH?^r^"''^^^-='^^ 
reception. A control p'roES S^^^^^^^ « 
and a mobile is used in ^nrhT ® base-station 

base-station decides me vS , it 
■0049] Note that ^,!^h * ^ use 

equirL for up^^ ^ ^^^^^^^^^^^^^^ may not be 

^obilewithoutcausfnganyconf«Ss ^'T"^ *° "^^^ 
^ not done when multSst °g S,,^^^^^^^ 



£^^obiS^r^~ 
^fCM/yW control messages. A VC REnJ^^? 
sage .s used by a mobile to rJuZ ihll 
provide a VC for sending da JTl^C ^fA'^TJ'^" *° 
sage is used by the base-stfl«ln » . ^^<^'-A/M mes- 
to the mobile, ^he base^S^lTn *° • 
determine the V<? aSviS S S^^"^ ^ '"^^^ ^ 
when the timer LSs Z ^ '^^CMZ/W 

that VC. ^ ' "° activity occurs on 

the same VC for Z m I ^ '"^°'P°^ated. If 

number of senders is uTS"''k ^^^P'»« t^e 

detect packet fframe/ ho ^ base-station that can 

"ows in'Jo a1i^'rv%tT4ri w^"^^ ""'"^'^ 
merge capable base-stpL?^ ^^"^ ^"^^ ^ VC- 
VC is usi for^Sy 'in T^'T' ' 

such a case, the base-Sn ' 9''°"P- 
<senderlPaddrLses T'"*""" ^ '"^PP'^S °' 

This implies thj each m^ ^^^^ss. VC # ) . 

the same IP muItSst gr^p' '"""'P'^ ^^s for 

Sy bl^idSsTt^he Pen- 
typicalirsS ?o?a ^thT'^T^f ^ '^'•^adcast is 
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ested in a paSiar L J f """^'"^ 
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network interfece from which a Query was received. To 
avoid an implosion of concurrent Reports and to reduce 
the total number of Reports transmitted, conventional 
IGMP uses two techniques: 

5 

1 . A randomly-chosen delay timer value. Response 
to a Query is generated when the timer expires. 
This helps spreading out the responses in time. 

2. The response Report Is addressed to the host 
group address with TTL set to 1 . Other members of io 
the same group on the same network can overhear 

the Report and suppress from generating another 
Report for that group. This reduces the IGMP over- 
load. 

15 

[0057] To achieve similar behavior on a wireless ATM 
system, the following modifications/extensions to IGMP 
are made according to the present invention: 

1. Downlink IGMP messages (Queries) are trans- 20 
mitted on the broadcast VC (from the base-station 

to the mobiles). All multicast capable mobiles 
(Hosts) receive the IGMP and Query messages 
and generate appropriate Reports, Non-multicast 
capable mobiles may also receive these messages. 25 
but these massages are dropped at the IP level. 

2. Uplink IGMP messages (Reports) are transmit- 
ted on the same unicast control VC. On receiving 
the Reports, the base-station rebroadcasts them so 
that other mobiles can receive the Report gener- 30 
ated by a host (mobile) belonging to a multicast 
group. If another host is a member of the same 
group, it resets its timer, keeping It from generating 
another Repxjrt. 

35 

IVC. New mobile Joining or leaving a multicast 
group 

[0058] The steps involved in performing a multicast 
operation where a new mobile joins the wireless ATM 40 
system according to a preferred embodiment Is pro- 
vided herein. Referring to figure 2 ,M1,M2 and M3 are 
three mobiles currently associated with the base-sta- 
tion. The method will be described considering a case 
where mobiles Ml and M2 join a multicast group, for 45 
example 225.1.1.1. receive multicast data and finally 
leave the group. 

[0059] The base-station needs to decide when to add 
or delete a mapping from its database, so that the 
mobiles can join or leave a group properly Adding a so 
new entry is relatively easy When a mobile joins a mul- 
ticast group and a mapping for this group doesn't 
already exist in the database, a new entry is added. 
However, deciding when to delete an entry from the 
database, the base-station needs to be sure that no 55 
more mobiles are associated with that particular multi- 
cast group address. In order to obtain such information, 
the base-station can maintain the mapping database in 



three different ways. 



1. Mapping of Source IP address, ( Multicast Group 
Address. VC Number ) . Ust of Mobile IP addresses 
joining this group. 

2. Mapping of Source IP address, (Multicast Group 
address, VC number), Counter (or flag). 

3. Mapping of Source IP address. (Multicast Group 
address, VC number). 

[0060] In the first case, a complete database of all the 
mobiles associated with the multicast group is main- 
tained. Having a complete mapping provides a lot of 
flexibility and functionality but has the advantage of 
increased complexity of maintaining the database. 
[0061] In the second case, the base-station simply 
maintains a counter that is incremented when a mobile 
joins that group and decreased when it leaves the 
group. When all mobiles have left the group, the counter 
would be zero and the entry can be safely deleted from 
the group. Note that, it may not even be necessary to 
keep track of how many mobiles are currently associ- 
ated with that group address. One may simply use a flag 
(states 0 and 1) that is set to 1 as long as at least one 
mobile is preset and set to zero (reset) when no mobiles 
are present. 

[0062] In the third case, the information about the 
presence of mobiles associated with that particular mul- 
ticast group address can be implicitly assumed from the 
multicast routing protocol. When no mobiles are associ- 
ated with the multicast group, the base-station (also a 
multicast router) sends a prune message to the 
upstream router to prune multicast traffic for that group. 
This message is generated by the multicast routing pro- 
tocol only when there are no hosts (mobiles) associated 
with that multicast group. This can be used to trigger the 
deletion of the entry from the database. 
[0063] Assuming IGMPv2 or greater, the following 
sequences of operation take place: 

When a mobile enters the area controlled by a 
base-station (commonly referred to as a Cell), it ini- 
tiates contact with the base-station over the wire- 
less control channel, which is a radio level 
communication mechanism. 
The base-station responds by providing, along with 
other information, a broadcast VC number and a 
unicast control VC number that the mobile should 
use. 

Mobile Ml decides to join the IP multicast group 
225.1.1.1. It sends an IGMP join message on the 
control VC. If PIM-Dense Mode multicast routing 
protocol is used, the base-station generates a Graft 
message and sends it to the upstream router. 
The base-station then searches its database to see 
if a mapping of (group, VC number) exists, if it 
does not. the base-station picks a VC from the 
available VC pool and maps it to the multicast 
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acknowledgment when, it expires. This is useful when 
no more cells remain to be transmitted or when there Is 
a long gap in the data stream. Since a NACK based 
mechanism for error recovery is used, a way of inform- 
ing the receivers that the cells were transmitted Is 5 
required. Normally, when there are more data to send, 
the transmitter resets the gratuitous ack timer, since the 
reception of the subsequent cells by the receivers is an 
indication that the previous group of cells were lost. The 
receiver generates an appropriate NACK packet with 10 
the right bitmap vector to recover the lost cells,. Never- 
theless, when the transmitter has transmitted the last 
group of cells (or the group before a long gap), cell loss 
may go undetected by the receivers, since it does not 
know that they were transmitted at all. In such cases, 75 
the transmitter sends a gratuitous ACK, indicating that a 
group of cells were transmitted. If a receiver receives a 
gratuitous ACK containing the sequence numbers of 
the transmitted cells, it can determine if a cell loss 
occurred and send back a NACK indication. Note that 20 
the reason for having a smaller timeout value is to give 
the receivers a chance for generating a NACK and 
recovering the lost cells before the retransmit timer 
expires. 



V. CONCLUSIONS 



ity of output ports with the unused VCI without 
using hop by hop massaging, thereby setting a 
switched path, 

wherein said ATM switch transports ATM cells 
through said one of a plurality of output ports 
without control of the router when each of the 
ATM cells has a VCI identical to the unused 
VCI, 

wherein multicast Virtual Channels (VCs) are 
obtained by mapping addresses corresponding 
to IP multicast groups to VC numbers corre- 
sponding to said multicast VCs, and 
wherein at least one base-station uses said 
mapping to provide VC numbers to new 
mobiles joining one of said IP multicast groups. 

The system of claim 1 wherein the base-station 
decides a correspondence between VCs and 
mobiles. 



3. The system of claim 1 wherein a uni-directional 
broadcast VC from the base-station to mobiles and 
a bi-directional control VCs between the base-sta- 
tion and the mobiles for sending control messages 
25 are pre-configured. 



[0069] In this Invention a mechanism for providing IP 
multicast for wireless ATM system is provided. To differ- 
entiate different types of traffic. VCs are classified into 30 
unicast, multicast and broadcast VCs. A control protocol 
between the base-station and mobiles is used to pro- 
vide the mobiles with the appropriate multicast VC 
number to use when joining a particular IP multicast 
group. Small modifications/extensions to the IGMP pro- 35 
tocol are provided, specifically to be used in wireless 
ATM systems. Finally to improve the effective through- 
put at the transport layer, a data link control protocol 
with negative acknowledgment is described. 
[0070] Other modifications and variations to the inven- 40 
tion will be apparent to those skilled in the art from the 
foregoing disclosure and teachings. Thus, while only 
certain embodiments of the invention have been specif- 
ically described herein, it will be apparent that numer- 
ous modifications may be made thereto without 45 
departing from the spirit and scope of the invention. 

Claims 

1. A network system having a predetermined protocol 50 
for transmitting a packet flow through an ATM net- 
work to a destination, said system comprising: 

a source for transmitting a sequence of ATM 
cells using an unused Virtual Channel Identifier S5 
(VCI): and 

a node comprising a router, and an ATM switch, 
wherein said router associates one of a plural- 



4. The system of claim 1 wherein control protocol 
between the base-station and mobiles comprises a 
VC REQUEST and a VC RECLAIM control mes- 
sages. 

wherein said VC REQUEST message is used by a 
mobile to request the base-station for a VC to send 
data, and 

wherein said VC RECLAIM message is used by the 
base-station to reclaim the VC assigned to the 
mobile. 

5. The system of claim 1. wherein said base-station is 
capable of detecting packet boundaries and merge 
multiple flows into a single VC, 

6. The system of claim 1 , wherein said base-station 
maintains mappings between sender IP address, 
multicast group address and VC number. 

7. The system of claim 1, wherein Internet Group 
Management Protocol (IGMP) is extended such 
that queries in the form of downlink IGMP mes- 
sages are transmitted on broadcast VC. 
wherein multicast mobiles receive said IGMP mes- 
sages and generate appropriate reports, and 
wherein nonmulticast mobiles drop said IGMP mes- 
sages at IP level. 

8. The system of claim 1, wherein Internet Group 
Management Protocol (IGMP) is extended such 
that reports in the form of uplink IGMP messages to 
a base station are transmitted on a unicast control 
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message!, and ^^^''^^ 'GMP 

reports being gener^Jld 

9. The system of claim 4 wherein thn k=- . . 
uses a timer to determine artr^T^a'^'c'S'T 
and reclaims the VC on said t^Xg " 

10. The system of claim 6. wherein tha k, . 
periodically broadcasts ThL !! ® '^^se-station 
mobiles not interesfe^ in a mess^ST''' 

ment (NACK)' scheme wher^aT^f'^'^'^'S^- 
corrupted cells. receiver has received 

30 



sequence numbers of transmitted cells th^ 
determines if a cell Iokq r,^^ ^ ' •'ecei^^? 
NAfk- ^ occurred and send har^, 

NACK message indicating that » ,.«.irr ^ ^ 
occurred. ^ ^ 'oss has 



groupTJif ''™««' last 

55 

The system of claim 16. wherein whpn th^ 
-erp/voe . ■ • '^''^'"wnen the receiver 

eceives the gratutoue: Aru' rv,^ reiver 
y aiuitous ACK message containing 



45 



cast VCs. w'^oaacast VCs and multi- 

^ are mapped to said unicast VCs. 

are mapped to said multicast VCs. 
21. The system of claim i« u,k~ ■ 

(c) sending an IGMP join messan*. 

trol VC; message on the con- 

(d) searching a base-station database to see if 
a^mapping of (multicast group. .oZZVo 

(e) picking a VC from available vr nr.r,, . 




S3- The „,e»,o<l o( *lm 22 ,„„he, comprising: 

m\ .^u ' ^'^ " ^^'Q t'mer expires; 
mKebroadcasting the host membership report; 
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receiving the rebroadcast of step m. 

24. A method of leaving a multicast group for a mobile* 
said method comprising: 5 

(a) sending an IGMP leave message to base 
station using control VC; 

(b) decrementing a counter associated with a 
corresponding VC; 10 

(c) checking to see if said counter has reached 
zero: 

(d) continuing transmission on the VC in step b 
if counter has not reached zero in step c; 

(e) closing corresponding VC for the mobile; is 
and 

(f) sending a prune message if all counters go 
below zero; 



25. A method of mapping mobiles with multicast groups 20 
for use in deleting said mobiles from said multicast 
groups said method comprises maintaining a data- 
base of all mobiles associated with the multicast 
group and mapping a multicast group with a subset 

of all mobiles joining the multicast group. 25 

26. A method of mapping mobiles with multicast groups 
for use in deleting said mobiles from said multicast 
groups said method comprise mapping a multicast 
group with a counter, wherein the counter is incre- 30 
mented when a mobile joins the multicast group 
and decreased when the mobile leaves the multi- 
cast group. 

27. A method of mapping mobiles with multicast groups 35 
for use in deleting said mobiles from said multicast 
groups said method comprises implicitly assuming 
absence of mobiles when a prune message is sent 
upstream. 
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